As computerized systems have increased in popularity, so have the needs to distribute files and processing resources of computer systems in networks both large and small. In general, computer systems and related devices communicate information over a network for a variety of reasons, for example, to exchange personal electronic messages, sell merchandise, provide account information, and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with sharing data and resources on a network have also increased.
Generally, there are a number of different mechanisms and protocols for distributing resources among computer systems. For example, two or more computers in a corporate network can share resources, such as files, application programs, or the like, over, for example, a Local Area Network (“LAN”), or a Wide Area Network (“WAN”). The computers can share these resources using any number of currently available transmit and receive communication protocols established between them.
More complicated schematics for sharing resources on a network include, for example, a domain controller hierarchy scheme, which is used in some implementations to organize and share both secure and non-secure resources in an efficient manner. For example, a central hub domain controller might be used to manage user names, passwords, computer names, network identifiers, or the like, and provide the information through a hierarchy of remote and local servers (i.e., local domain controllers). The various domain controllers, in turn, are configured with a resource manager, such as a Security Account Manager (“SAM”), which provides interfaces and protocols for storing or authenticating resources in the domain. When one or more individual client computer systems requests a resource, the request may be handled by a local domain controller based on a policy provided by a higher level computer in the domain.
In one example, a large pharmaceutical company that has several local branch offices (e.g., neighborhood pharmacies), might want to establish a local domain controller at each of the different local pharmacies. The company might do so by establishing a domain controller at each branch office. Each different branch office might therefore be part of a sub-domain in the hierarchy, or might even represent its own individual sub-domain of yet another sub-domain in the company's domain hierarchy. The established domain controller is typically configured for, among other things, operating in accordance with resource guidelines pushed downward from the centralized hub domain controller.
In this example, the hub domain controller might be “writable” or configured to be written-to by an administrator in the main organization. By contrast, the local domain controllers to which the central writable domain controller connect in this example, however, might be “read-only”, and not therefore configured to be written-to in any meaningful way by the local users, or sometimes even the network administrator. In such an example, each local domain controller would be configured primarily to operate in accordance with guidelines provided by the writable domain controller. For user requests, the local domain might also be configured simply to relay the user requests to the writable hub domain controller, and then pass along the relevant account approval information sent back from the hub domain controller. For example, a user logs onto a client machine, and the local domain controller forwards the request to the hub domain controller for authentication. If the hub domain controller verifies the user's entered information, the hub domain controller instructs the local domain controller to allow the user to logon to the client computer system.
While this example schematic might have an advantage of being highly centralized, it also has a number of different difficulties, such as a low degree of local configurability (or none at all) for the various local domain controllers. For example, in order for a user to change a password (or reconfigure another resource), the user will usually need to contact an administrator managing the hub domain controller, who will then change the password (or resource) at the hub domain controller before the user can use the new password (or resource) at the local branch. That is, read-only domain controllers are typically unable to chain, or forward, secure account management requests from a user to hub domain controller.
Furthermore, although minimizing the amount of technical support staff needed at the local branch, this centralized domain controller schematic represents a single point of failure throughout the entire company's network. For example, when the hub domain controller is unavailable for any reason, users at the local branch might be unable to access a certain resource (e.g., logon to their respective client computer systems). That is, the local read-only domain controller will not store the relevant information from the hub domain controller that could be used to validate the client's request(s).
Alternative implementations to the foregoing examples include local and hub domain controllers that are each writable. Under this type of schematic, the hub domain controller sends not just resource configuration information, but also security account information for the company or organization, such that each local domain controller stores all security accounts for the company. Thus, when any user of the company logs onto any client machine at any local branch, the local domain controller, rather than the hub domain controller, authenticates the user(s), and provides client computer system access.
Since resources such as these are stored locally, the user may also be able to configure other resources at the local domain controller, such as the share-ability of a certain file, or access to another file system, or the like. Furthermore, an appropriately authorized user, can also change or update certain security account (or other configuration) information at the local domain controller, as opposed to changing this information by dealing with the network administrator of the hub domain controller. Changes at the user's local domain controller are then propagated throughout the other local and remote domain controllers in the hierarchy.
While this writable local and remote domain controller schematic has an advantage of decentralizing domain controller configurability and access, this schematic can also present other potential problems, such as security issues, when used in local branch offices that do not have trained technical support staff. For example, there is a heightened risk that one of the local users at a local branch might inadvertently modify a resource at the local domain controller that should not be modified. This is possible in part since many resources in present operating systems now come with a high degree of configuration granularity, which is difficult, if not impossible, for many non-technical branch users to successfully navigate. If there is no local technical support when a configuration mistake is made, the local branch might have to wait until a trained network administrator can fix the problem on-site, or fix it over the company's network as available.
One can appreciate that the writable local and remote domain controller schematic also presents a variety of exposure concerns. For example, the local domain controllers in the prior example may be accessible by other local domain controllers on the company network, and sometimes also by others on an outside, non-corporate network (e.g., Internet). Furthermore, the writable local domain controllers can present heightened security risks due to physical intrusion concerns, since, as a practical matter, organizations tend not to place the local domain controllers in physical secure locations. That is, the organization may want the benefits of a writable local domain controller, but not want to expend the resources to guard against virtual and physical security risks. Such physical risks can include removal or replacement of server hardware (e.g., hard drives, and the like).
As such, a number of difficulties can be found both with schematics with one writable domain controller and those with all domain controllers being writable, particular when implemented in branch locations that are separated from a head office location.